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BACKGROUND OF THE INVENTION— FIELD OF INVENTION 

This invention relates to computing, or processing machine storage, specifically to an 
improved method to expand the capacity of native storage. 

BACKGROUND OF THE INVENTION 

On-line storage usage in the home is growing, and growing rapidly. In fact the appetite 
for storage in the home is almost limitless. Applications and uses driving storage in the 
home are becoming widespread and include, but are not limited to games on the PC and 
game boxes for the TV, digital video capture and display devices (e.g. Digital Video Players 
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and Recorders (DVR), Personal Video Recorders (PVR) (e.g. ReplayTV™ and TiVo™), ...), 
home answering machines, emerging home entertainment HUBS and centers, audio (MP3), 
digital cameras, Internet downloads (photos, video clips, etc) as well other general data 
stored on PCs. 

The explosion in Digital Video and Image capture and distribution (through digital video 
recorders, or digital cameras) is creating a problem of particular note as much of the digital 
imagery data created and stored in the home today is fleeting due to data storage constraints. 
With film, pictures are taken, developed into photos, and then kept in an album (or a 
shoebox) for as long as you want, and with the negatives you can make more pictures at 
anytime in the future. If you need more storage space you simply buy another album or pair 
of shoes. On the other hand, Digital images (either still or motion) require large amounts of 
data storage capability. Once the capacity of the data storage device is consumed, it becomes 
necessary to either a) delete existing data or images to make space available for the new 
images or data, or, b) find a way to add or increase storage capacity. Either of which can be 
painful either from the loss of data or the associated challenges of increasing on-line storage 
capacity. . Users require convenient, easily expandable and manageable on-line storage to 
retain all of these digital images. 

In addition to the problem of limited storage resources, the disparate sources of digital 
data indicate the need for a common, central area for storage to enable sharing, and a 
consistent set of application interfaces and formats. Otherwise countless types of storage are 
required, with differing application interfaces and usage models adapted to the multitude of 
storage formats. 

Finally, the solution must be local (with potential extensions to the Internet). For the 
private individual, the solution must be at home. In the case of a small office, or home office, 
the solution must be in the office. People want their data local where they have ready access, 
security, and control, not remotely with a Storage Service Provider (SSP). While this may 
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change, currently, the SSP model does not provide the security that folks want (much of the 
data they save is private, and Storage Service Providers have not proven themselves yet). 

The issues and concepts above indicate that there is a huge need for additional, easily 
expandable and sharable storage in the home. Yet, while the need exists there is no readily 
available technology that provides a solution. Today, system devices, or information 
appliances (e.g. a computer, a personal computer, an entertainment hub, a game box, a 
personal digital assistant, a data or information recorder, a data storage system, a data server, 
a digital camera, a household appliance, an automobile, a transportation device, a mobile 
telephone, a communications device, and combinations thereof) are shipped, and typically 
optimized for use with a single, internal storage element. As outlined above, this model is not 
sufficient to satisfy the growing needs of the current home or small business user. Current 
solutions to expand the available storage capacity encompass the following general forms: 

(1) Resident solutions (i.e. - inside the home) Within the home environment there are 

four major expansion solutions. 

(a) First add an additional storage element (disk) to the system - The main benefit of 
this approach is it mitigates the potentially challenging need to migrate the data and 
applications residing on the native storage device(s) to the larger device. The main drawback 
is increased management complexity of multiple storage elements/devices and the inability to 
share data with other systems. You have two choices here: 

(i) Add an additional, internal storage device to your system, or information 
appliance. Typically this implies opening the system, which may or may not, violate the 
manufactures warranty. In those instances where you can add an internal device, it is a 
complex task better handled by an experienced technician and not the typical layperson. 
Once the additional storage device/element is successfully added to the system and is 
operating properly, the user must now manage the additional storage element as a separate 
and distinct logical and/or physical storage element from any of the original native storage 
element(s). Each time another physical storage element is added, the user must manage 
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another element. As this number grows the management task becomes harder and more 
cumbersome. Once you've filled up your internal expansion capacity, or are not up to the 
challenges of adding internally based storage, you can move on to the next choice. 

(ii) Instead of opening up your machine's chassis you can add an external, direct 
attached storage device. These are typically connected via, but not limited to, IDE, SCSI, 
USB, Fire Wire, Ethernet, or other direct or networked attached interface mechanisms. While 
mechanically simpler than adding an internal device not all systems or information 
appliances are setup to support external devices. Here again, as in (i) above, the management 
complexity of multiple storage elements grows as each new element is added. 

(b) The second solution is to continually replace the native storage element (i.e. disk 
drive) with a larger disk drive. The primary advantage to this approach is once the data 
applications have been successfully migrated; only one storage element need be managed. 
The main drawback is the need to successfully migrate the data to the new storage element 
and any compatibility issues for both the BIOS and OS of the system to support the larger 
capacity storage elements, as well as the lack of data sharing capabilities. This can work in 
either the internal or external device solutions outlined above. The problems here are two- 
fold: 

(i) First, you have all the issues outlined under (l)(a)(i) (if you're replacing an 
internal storage device) or (l)(a)(ii) (if you're replacing an external storage device). While 
you can, continually, replace with bigger and bigger drives (and thus not hit a physical slot, 
address, or other mechanical limitation) you will, eventually, run into a technical limit with 
the compatibility of the newer technology within the older chassis. 

(ii) Second, many users have more data than can be stored on even the largest of 
the commercially available home disk device products. This forces the user to buy more than 
one device and opens up all the problems already listed. 

(c) The third solution, and typically the most costly and distasteful is to replace the 
entire system or information appliance with one that has more storage. While a simple 
upgrade, physically, you run into a major problem in migrating all of your data, replicating 
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your application environment and, basically, returning to your previous computing status quo 
on the new platform. 

(d) The fourth solution is to connect to some sort of network-attached home File 
Server (or Filer). This solution only works however if the system or information appliance is 
capable of accessing remote Filers. This solution is an elaboration of (l)(a)(ii). A simple 
home Filer can allow for greater degrees of expansion, as well as provide for the capability of 
sharing data with other systems. However, this solution is significantly more complex than 
the above solutions as you must now "mount" the additional storage, then "map" the drive 
into your system. As in the above solutions, you now have additional storage element/devices 
to manage as well as the added requirement to manage shared network environment. All of 
which adds ongoing complexity, particularly for the typical layperson. 

(2) Non-Resident solutions (i.e. - outside the home) - The basic premise here is that you 
can utilize an Internet based storage solution with a 3 rd party Storage Service Provider. The 
first issue here is that you have no direct control over the availability of your data; you must 
rely upon the robustness of the Internet to ensure your access. In addition, performance will 
be an issue. Finally, costs are typically high. 

In summary, the problems with the existing solutions (outlined above) are the following: 

(1) Online storage Expansion is complex - Once the many issues and challenges have 
been overcome in simply adding either an additional storage element or replacing the 
existing element with a larger one, either internally or externally, a new set of problems arise 
in the management and utilization of the new storage configuration. None of which can 
guarantee a seamless, transparent upgrade path to add more storage capacity in the future. 

(2) Expansion is limited - Unless you are adding an external Filer the solutions are 
limited in terms of the degree of expandability. Typically, no more than two disk storage 
devices can be housed in today's PC (some can manage up to four). Either cabling, 
addressing, or PCI slot limitations will also limit the number of external devices that can be 
added. 
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(3) Ongoing management is complex - Each additional drive, or mount point (for Filer 
attached drives) is treated as a separate storage element and must be configured, mounted and 
managed individually. In no case can you simply increase the size of your existing disk drive 
or element. This is true regardless of whether you are attempting to expand a primary, or 
native, drive (in this document the primary, or native drive, or storage element, implies that 
storage element required for basic operation of the processing or computing element; e.g. the 
"C" drive in Windows machines) or any other current attached and configured storage 
element. While you can concatenate, or stripe drives together, in some cases, to increase a 
drive's capacity, doing this to an existing drive can be complex, not recommended, or even 
not possible (as in the case of your boot device, which is usually, again, your existing 
primary, or native, drive). These more complex storage configurations (concatenations, 
mirrors, stripes) are also not available in today's Home Entertainment Hubs. 

(4) Data migration - This is an issue if you are replacing a smaller device with a larger 
one, or replacing the entire unit or machine. Inaccurate migration of data and applications can 
result in loss of data and the improper function or failure of applications. Any or all of 
which can result in a catastrophic failure. 

(5) Sharing is difficult or impossible - Unless you have a home network and are adding a 
home Filer you cannot share any of the storage you added. In addition, even home Filers are 
not able to share storage with non-PC type devices (e.g. Home Entertainment Hubs). There 
are emerging home Filers, but these units still must be configured on a network, setup and 
managed - again, beyond most user's capabilities and they don't address the storage 
demands of the emerging home entertainment systems. Trying to concatenate an internal 
drive with an external drive (i.e. - mounted from a Filer) is difficult, at best, and impossible 
in many instances. 

While we have described, above, the various methods that can be used to add storage 
capacity to computing environments, there is currently no technology available that can be 
used to easily expand, consolidate, share and migrate data in such a manner that your existing 
storage element's capacity is transparently increased. Expansion of storage has been 
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approached in a number of ways. A number of techniques have been employed to alter the 
way storage is perceived by a user or application. 

United States patent number 6,591,356 B2, named Cluster Buster, presents a mechanism 
to increase the storage utilization of a file system that relies on a fixed number of clusters per 
logical volume. The main premise of the Cluster Buster is that for a file system that uses a 
cluster (cluster being some number of physical disk sectors) as the minimum disk storage 
entity, and a fixed number of cluster addresses; a small logical disk is more efficient than a 
large logical disk for storing small amounts of data. (Allow small here to be enough data only 
to fill a physical disk sector.) An example of such a file system is the Windows FAT 16 file 
system. This system uses 16 bits of addressing to store all possible cluster addresses. This 
implies a fixed number of cluster addresses are available. Thus, to store the same number of 
clusters on a "small" logical partition, versus a "very large" logical partition, the number of 
sectors within a cluster must be made larger for the "very large" logical partition. In such a 
case storing data that occupies one disk sector would waste storage space within the very 
large logical partition's cluster. To make use of large storage devices more efficient, the 
Cluster Buster divides a large storage device into a number of small logical partitions, thus 
each logical partition has a small (in terms of disk sectors) cluster size. However, to aide the 
user/application from dealing the potentially large number of logical volumes a mechanism is 
inserted between the file system and the user/application. This mechanism presents a number 
of "large" logical volumes to the user/application. The application intercepts requests to the 
file system and replaces the requested logical volume with the actual (i.e. on one of the many 
small) logical volumes. 

In this system the smaller logical partitions are still initially created as standard logical 
volumes for the file system. In the Windows case, this would be the familiar alphabetic 
name; e.g. D:, E:, F:, G:, H:, etc. The Cluster Buster mechanism bundles together a number 
of the smaller logical volumes, and presents them as some logical volume. So, logical 
volumes D:, E:, F:, G:, and H: might be presented simply as the D: logical volume. The file 
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systems still must recognize all of the created logical volumes, but the Cluster Buster 
mechanism takes care of determining the logical volume access requested of the file system. 

The Cluster Buster mechanism is different from the current invention in that Cluster 
Buster is above the file system, and Cluster Buster requires that a number of logical volumes 
be created and each logical volume is directly accessible by the file system. 

United States patent 6,216,202 Bl describes a computer system with a process and an 
attached storage system. The storage system contains a plurality of disk drives and associated 
controllers and provides a plurality of logical volumes. The logical volumes are combined, 
within the storage system, into a virtual volume(s), which is then presented to the processor 
along with information for the processor to deconstruct the virtual volume(s) into the 
plurality of logical volumes, as they exist within the storage system, for subsequent processor 
access. Additional application is presented to manage the multi-path connection between the 
processor and the storage system to address the plethora of connections constructed in an 
open systems, multi-path environment. 

The current invention creates a "merged storage construct" that is perceived as an 
increase in size of a native storage element. The current invention provides no possible way 
of deconstruction of the merged storage construct for individual access to a member element. 
The merged storage construct is viewed simply as a native storage device by the processing 
element, a user or an application. 

United States Patent application 2002/0129216 Al describes a mechanism to utilize 
"pockets" of storage in a distributed network setting as logical devices for use by a device on 
the network. The current invention can utilize storage that is already part a merged storage 
construct and is accessible in a geographically dispersed environment. Such dispersed 
storage is never identified as a "logical device" to any operating system, or file system 
component. All geographically dispersed storage becomes part of a merged storage construct 
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associated specifically with some computer system somewhere on the geographically 
dispersed environment. That is to say, some computer's native drive becomes larger based 
on storage located some distance away, or to say in a different way, a part of some 
computer's merged storage construct is geographically distant. 

Additionally, United States patent numbers 6,366,988 Bl, 6,356,915 Bl, and 6,363,400 
Bl describe mechanisms that utilize installable file systems, virtual file system drivers, or 
interception of API calls to the Operating System to provide logical volume creation and 
access. The manifestation of these mechanisms may be as a visual presentation to the user or 
to modify access by an application. These are different from the current invention in that the 
current invention does not create new logical volumes but does create a merged storage 
construct presenting a larger native storage element capacity, which is accessed utilizing 
standard native Operating System and native File Systems calls. 

The current invention takes a different approach from the prior art. The fundamental 
concept of the current invention is: To abstract the underlying storage architecture in order to 
present a "normal" view. Here, "normal" simply means the view that the user or application 
would typically have of a native storage element. This is a key differentiator of the current 
invention from the prior art. The current invention selectively merges added storage with a 
native storage element to represent the abstracted merged storage, or merged storage 
construct, simply as a larger native storage element. The mechanism of the current invention 
does not register any added storage in the sense of creating an entity directly accessible by 
the operating system or the file system; no additional "logical volumes" viewable by the file 
system are created, nor is a component merged with the native storage element accessible 
except via normal accesses directed to the abstracted native storage element. Such accesses 
are made utilizing standard native Operating System and native File Systems calls. 

The added storage is merged, with the native storage, at a point below the file system. 
The added storage, while increasing the native storage component is not required to be 
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geographically co-located with the native storage element. Additionally, the merged storage 
elements themselves may be geographically dispersed. 

SUMMARY 

In accordance with the present invention, an electronic storage expansion technique 
comprises a set of, methods, systems and computer program products or processes that 
enable information appliances (e.g. a computer, a personal computer, an entertainment 
hub/center, a game box, digital video recorder / personal video recorder, a personal digital 
assistant, a data or information recorder, a data storage system, a data server, a digital 
camera, a household appliance, an automobile, a transportation device, a mobile telephone, a 
communications device, and combinations thereof) to transparently increase their native 
storage capacities. 

DRAWINGS - FIGURES 

In the drawings, closely related figures, and figure elements, have the same number but 
different alphabetic suffixes. The general instance of any element will have the numeric label 
only; a specific instance will add an alphabetic suffix character. 

Fig 1 shows the overall operating environment and elements at the most abstract level. 
All of the major elements are shown (including items not directly related to patentable 
elements, but pertinent to understanding of overall environment). It illustrates a simple home, 
or small office environment with multiple PCs and a Home Entertainment Hub.. 

Fig la adds a home network view to the environment outlined in Fig 1 

Fig 2 shows a myriad of, but not necessarily all encompassing set of, choices for adding 
storage to the environment outlined in Fig 1 and Fig la. 

Fig 2a shows a generic PC with internal drives and an external stand-alone storage device 
connected to the PC chassis. 
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Fig 2b illustrates an environment consisting of a standard PC with External Storage 
subsystem interconnected through a home network 

Fig 3 illustrates the basic intelligent blocks, processes or means necessary to implement 
the preferred embodiment. It outlines the elements required in a client (Std PC Chassis or 
Hub) as well as an external intelligent storage subsystem. 

Fig 3a shows a single, generic PC Chassis with internal drives and an external stand- 
alone storage device connected to the disk interface. 

Fig 3b shows a single, generic PC Chassis with an internal drive and an External Storage 
Subsystem device connected via a network interface. 

Fig 3c shows multiple; standard PC Chassis along with a Home Entertainment Hub all 
directly connected an External Storage Subsystem. 

Fig 4 illustrates the Home Storage Object Architecture (HSOA) Storage Abstraction 
Layer (SAL) processes internal to a client provided with the methods and means required to 
implement the current invention 

Fig 4a illustrates the Home Storage Object Architecture (HSOA) Storage Abstraction 
Layer (SAL) processes internal to a client provided with the methods and means required to 
implement the shared client-attached storage device aspects of the current invention. 

Fig 4b illustrates the Home Storage Object Architecture (HSOA) Shared Storage 
Abstraction Layer (SSAL) processes internal to a client provided with the methods and 
means required to implement the shared data aspects of the current invention. 

Fig 4c illustrates the Home Storage Object Architecture (HSOA) Storage Abstraction 
Layer (SAL) processes internal to a client provided with the methods and means required to 
implement the shared data aspects of the current invention. 

Fig 5 illustrates the processes internal to an enabled intelligent External Storage 
Subsystem that is connected via a network interface. 

Fig 5a illustrates the processes internal to an enabled intelligent External Storage 
Subsystem that is connected via a disk interface. 

Fig 6 illustrates the output from the execution of a "Properties" command on a standard 
Windows 2000 attached disk drive prior to the addition of any storage. 
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Fig 7 illustrates the output from the execution of a "Properties" command on a standard 
Windows 2000 attached disk drive subsequent to the addition of storage enabled by the 
methods and processes of this invention. 

Fig 8 illustrates the processes internal to a client provided with the methods and means 
required to implement the shared data aspects of the current invention. 

Fig 8a illustrates an alternative set of processes and communication paths internal to a 
client provided with the methods and means required to implement the shared data aspects of 
the current invention. 

Fig 9 illustrates a logical partitioning of an external device or logical volume within an 
external storage subsystem. 
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DETAILED DESCRIPTION 

A preferred embodiment of the storage expansion of the present invention is illustrated in 
Figs 1, 2, 3, 4 and 5. These figures outline the, methods, systems and computer program 
products or processes claimed in this invention. Fig 1 illustrates a computing, or processing, 
environment that could contain the invention. The environment may have one, or more, 
information appliances (e.g. personal computer systems 10a and 10b). Each said personal 
computer system 10a and 10b typically consists of a monitor element 101a and 101b, a 
keyboard 102a and 102b and a standard tower chassis, or desktop element 100a and 100b. 
Each said chassis element 100a and 100b typically contains the processing, or computing 
engines and software (refer to Fig 3 for outline of software processes and means) and one, or 
more, native storage elements 103a, 104a and 103b. In addition to said personal computer 
systems 10a and 10b, the environment may contain a Home Entertainment Hub 13 (e.g. 
ReplayTV™ and TiVo™ devices). These said Hubs 13 are, typically, self-contained units 
with a single, internal native storage element 103c. Said Hubs 13 may, in turn, connect to 
various other media and entertainment devices. Connection to a video display device 12 via 
interconnect 4 or to a Personal Video Recorder 14, via interconnect 5 are two examples. 

Fig 2 illustrates possible methods of providing added storage capabilities to the 
environment outlined in Fig 1. Said chassis element 100a or Hub 13 may be connected via an 
interface and cable 8a and 6 to external, stand-alone storage devices 17a and 7. Alternatively 
an additional expansion drive 104b may be installed in said chassis 100b. Additionally, a 
Home Network 15 may be connected 9a, 9b, 9c and 9d to said personal computers 10a and 
10b as well as said Hub 13, and to an External Storage Subsystem 16. Connections 9a, 9b, 
9c and 9d may be physical wire based connections, or wireless. While the preferred 
embodiment described here is specific to a home based network, the network may also be a 
local area network (LAN), metropolitan area network (MAN), wide area network (WAN) or 
any combination of these. 
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Fig 3 illustrates the major internal processes and interfaces which make up the preferred 
embodiment of the current invention. Said chassis elements 100a and 100b as well as said 
Hub 13 contain a set of Storage Abstraction Layer (SAL) processes 400a, 400b and 400c. 
Said SAL processes 400a-400c utilize a connection mechanism 420a, 420b and 420c to 
interface with the appropriate File System 310a, 310b and 310c, or other OS interface. In 
addition, said SAL 400a-400c processes utilize a separate set of connection mechanisms 

• 460a, 460b and 460c to interface to a network driver 360a, 360b and 360c, 
and 

• 470a, 470b and 470c to interface to a disk driver 370a, 370b and 370c 
The network driver, in turn, utilizes Network Interfaces 361a, 361b and 361c and 
interconnection 9a, 9b and 9c to connect to the Home Network 15. Said Home Network 15 
connects via interconnection 9d to the External Storage Subsystem. The External Storage 
Subsystem may be a complex configuration of multiple drives and local intelligence, or it 
may be a simple single device element. Said disk driver 370a, 370b and 370c utilizes an 
internal disk interface 371a, 371b and 371c to connect 380a, 381a, 380b, 381b and 380c to 
said internal storage elements (native, or expansion) 103a, 103b, 103c, 104a, and 104b. Said 
Disk Driver 370a and 370c may utilize disk interface 372a, and 372c, and connections 8a 
and 6 to connect to the local, external stand-alone storage elements 17a and 7. 

An External Storage Subsystem may consist of a standard network interface 361d and 
network driver 360d. Said network driver 360d has an interface 510 to Storage Subsystem 
Management Software (SSMS) processes 500 which, in turn have an interface 560 to a 
standard disk driver 370d and disk interface 371d. Said disk driver 370d and said disk 
interface 371d then connect, using cables 382a, 382b, 382c and 382d, to the disk drives 
160a, 160b, 160c and 160d within said External Storage Subsystem 16. 

Fig 4 illustrates the internal make up and interfaces of said SAL processes 400a, 400b, 
and 400c (Fig 3). Said SAL processes 400a, 400b, and 400c (in Fig 3), are represented in Fig 
4 by the generic SAL process 400. Said SAL process 400 consists of a SAL File System 
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Interface means 420, which provides a connection mechanism between a standard File 
System 310 and a SAL Virtual Volume Manager means 430. A SAL Administration means 
440 connects to and works in conjunction with both said Volume Manager 430 and an 
Access Director means 450. Said Access Director 450 connects to a Network Driver 
Connection means 460 and a Disk Driver Connection means 470. Said driver connection 
means 460 and 470 in turn appropriately connect to a Network Driver 360 or a Disk Driver 
370, or 373. 

Fig 5 illustrates the internal make up and interfaces of said SSMS processes 500. Said 
SSMS processes 500 consist of a Storage Subsystem Client Manager means 520, which 
utilizes said Storage Subsystem Driver Connection means 510 to interface to the standard 
Network Driver 360 and Network Interface 361. Said Storage Subsystem Client Manager 
means 520 in turn interfaces with a Storage Subsystem Volume Manager means 540. A 
Storage Subsystem Administrative means 530 connects to both said Client Manager 520 and 
said Volume Manager 540. Said Volume Manager 540 utilizes a Storage Subsystem Disk 
Driver Connection means 560 to interface to the standard Disk Driver 370. 

OPERATION OF INVENTION - OVERVIEW 

In accordance with an embodiment of the present invention, methods, systems and 
computer program products or processes are provided for expansion, and management of 
storage. 

So, what is needed to accomplish these lofty concepts? There are actually two elements 
that are necessary. The first is a set of processes, or means, that transparently facilitates the 
ability for information appliances, or clients to utilize additional storage devices. 
Information appliances, or clients (the terms information appliance and client are used 
interchangeably), in the context of this invention, are any processing, or computing devices 
(e.g. a computer, a personal computer, an entertainment hub, a game box, a personal digital 
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assistant, a data or information recorder, a data storage system, a data server, a digital 
camera, a household appliance, an automobile, a transportation device, a mobile telephone, a 
communications device, and combinations thereof) with the ability to access storage. The 
second element is any additional storage. (Additional storage implies any electronic storage 
device other than a client's native, or boot storage device; e.g. in Windows-based PCs, the 
standard C-Drive). The combination of these processes and elements provide, for the home 
or small office, a virtual storage environment that can transparently expand any client's 
storage capacity. 

This section will introduce the "Home Shared Object Architecture" (HSOA). While the 
term "Home" is used as a reference, the embodiment (or its alternatives) is not limited to a 
"Home" environment. Much of the following discussion will make use of the term an 
"HSOA enabled client", or simply "client", and implies any information appliance that has 
been imbued with the processes and methods of this invention. 

The HSOA provides a basic storage expansion and virtualization architecture for use 
within a home network of information appliances. Figs 1,1a and 2 are examples of a home 
environment (or small office). Fig 1 illustrates an environment wherein various information 
appliances 10a, 10b and 13 may contain their own internal storage elements 103a, 104a, 
103b and 103c (again, just one example, as many of today's entertainment appliances contain 
no internal storage). In Fig 1, we see two types of information appliances. First, there is a 
Home Entertainment Hub (or just Hub) element 13. The Hub can be used to drive, or control 
many types of home entertainment devices (Televisions 120, Video Recorders 14, Set Top 
Box 121 (e.g. video game boxes), etc.) and may, or may not, have some form of Internet 
connectivity 18 (e.g. broadband interface, phone line, cable or satellite). Hubs 13 have, in 
general, very limited data storage (some newer appliances have disks). Second, there are 
home PC elements, or clients, 10a and 10b. These typically contain a keyboard 102a and 
102b, a monitor 101a and 101b, and a chassis 100a and 100b, which contains a processing 
engine, various interfaces and the internal drives 103a, 104a and 103b. Again, you may, or 
may not have an external Internet connection 19 (broadband or phone line) into this 
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environment, typically separate from the Hub 13 connectivity (even with a shared cable, the 
PC cable-modem is separate from the cable connections into your entertainment appliances). 
While Fig 1 illustrates a stand-alone environment (none of the system elements are 
interconnected with each other), Fig la shows a possible home network configuration. In this 
example a home network 15 is used with links 9a, 9b and 9c to interconnect intelligent 
system elements 10a, 10b and 13 together. This provides an environment wherein the 
intelligent system elements can communicate with one another (as mentioned previously this 
connectivity may be wire based, or wireless). While networked PCs can mount, or share (in 
some cases) external drives there is no common point of management. In addition, these 
network accessible drives cannot be used to expand the capacity of the native, internal drive. 
This is especially true when you add various consumer A/V electronics into the picture. 
Many other problems with storage expansion are outlined in the BACKGROUND OF THE 
INVENTION section. In Fig 2 an external storage subsystem 16 is connected 9d into the 
home network 15. This is, today, fairly atypical of home computing environments and more 
likely to be found in small office environments. However, it does represent a basic start to 
storage expansion. Examples of external storage subsystems 16 are a simple Network 
Attached Storage (NAS) box, small File Server element (Filer), or an iSCSI storage 
subsystem. These allow clients to access, over a network (wireless, or wire based), the 
external storage element. A network capable file system (e.g., Network File System, NFS, or 
Common Internet File System, CIFS) are, today, required for accessing NAS boxes or filers, 
while iSCSI devices are accessed through more standard disk driver mechanisms. In addition, 
complex management, configuration and setup are required to utilize this form of storage. 
Again, other problems and issues with these environments have been outlined in the 
BACKGROUND OF THE INVENTION section above. 

The basic premise for HSOA is an ability to share all the available storage capacities 
(regardless of the method of connectivity) amongst all information appliances, provide a 
central point of management and control, and allow transparent expansion of native storage 
devices. Each of these ideas is explained, independently, within the body of this patent. 
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OPERATION OF INVENTION - BASIC STORAGE EXPANSION 

The fundamental concept of the current invention is: To abstract the underlying storage 
architecture in order to present a "normal" view. Here, "normal" simply means the view that 
the user or application would typically have of a native storage element. This is a key 
differentiator of the current invention from the prior art. The current invention selectively 
merges added storage with a native storage element to represent the abstracted merged 
storage, or merged storage construct, simply as a larger native storage element. The 
mechanism of the current invention does not register any added storage in the sense of 
creating an entity directly accessible by the operating system or the file system; no additional 
"logical volumes" viewable by the file system or the operating system are created, nor is a 
component merged with the native storage element accessible except via normal accesses 
directed to the abstracted native storage element. Such accesses are made utilizing standard 
native Operating System and native File Systems calls. 

The added storage is merged, with the native storage, at a point below the file system. 
The added storage, while increasing the native storage component is not required to be 
geographically co-located with the native storage element. Additionally, the merged storage 
elements themselves may be geographically dispersed. 

The basic, and underlying concept is an easy and transparent expansion of a client's 
native storage element. In a Windows PC environment this implies expanding the capacity of 
one of the internal disk drives (e.g. C-Drive). A simple environment for this is illustrated in 
Fig 2a. In this figure an information appliance (e.g. a standard PC system element) 10 is 
shown with Chassis 100 and two native, internal storage elements 103 (C-Drive) and 104 (D- 
Drive), Additional storage in the form of ah external, stand-alone disk drive 17 is attached 
(via cable 8) to said Chassis 100. The processes embodied in this invention allow the 
capacity of storage element 17 to merge with the capacity of the native C-Drive 103 such that 
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the resulting capacity (as viewed by File System - FS, Operating System - OS, etc.) is the 
sum of both drives. This is illustrated in Figs 6 and 7. In Fig 6 we see the typical output 600 
of the Properties command on the native Windows boot, or C-Drive. Used space 610 is listed 
as 4.19 GB 620 (note, two capacity displays don't match exactly - listed bytes and GBs - as 
Windows takes some overhead for its own usage), while free space 630 is listed at 14.4GB 
640. This implies a disk of roughly 20 GB 650. If we then add (as an internal or external, 
stand-alone drive) a storage element with 120 GBs of capacity, and re-run the Properties 
command on the same, native Windows boot, or C-Drive we get the display as illustrated in 
Fig 7. Used space 710 remains the same at 4.19 GB 720, while Free space 730 is listed at 
126.2GB 740, which is the combined capacity of the old free space and the entire new 
storage element (as all the new space is free). This implies a disk of roughly 140 GB 750. 
No special management operations have taken place that required user intervention (as would 
be required by other, current methods). No one had to mount the new storage element 17 and 
Concatenate it with the C-Drive 103; no one had to even recognize that a new, separate drive 
existed. The FS and OS still view this as the standard, native internal C-Drive. 

How is this accomplished? Figs 3a and 4 outline the basic software functions and 
processes employed to enable this expansion. Fig 3a illustrates a Storage Abstraction (SAL) 
process 400, which resides within a standard system process stack. The SAL process, as 
illustrated in Fig 4, consists of a File System Interface 420, which intercepts any storage 
access from the File System 310 and packages the eventual response. This process, in 
conjunction with a SAL Virtual Volume Manager 430 handles any OS, Application, File 
System or utility request for data, storage or volume information. The SAL Virtual Volume 
Manager process 430 creates the logical volume view as seen by upper layers of the system's 
process stack and works with the File System Interface 420 to respond to system requests. An 
Access Director 450 provides the intelligence required to direct accesses to any of the 
following (as examples): 

1 . an internal storage element (103 in Fig 3a) through a Disk Driver Connection 
process 470, a Disk Driver-0 370, and a Disk Interface-0 371. 
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2. an External, Stand-alone Device (17 in Fig 3a) through a Disk Driver Connection 
process 470, a Disk Driver-0 370, and a Disk Interface-1 372. 

3. an External Storage Element (16 in Fig 3) through a Network Driver Connection 
process 460, a Network Driver 360, and a Network Interface 361 . 

The SAL Administration process 440 (Fig 4) is responsible for detecting the presence of 
added storage (see subsequent details) and generating a set of tables that the Access Director 
450 utilizes to steer the IO, and that the Virtual Volume Manager 430 uses to generate 
responses. The Administration process 440 has the capability to automatically configure 
itself onto a network (utilizing a standard HAVi, or UPnP mechanism, for example), discover 
any storage pool(s) and help mask their recognition and use by an Operating System and its 
utilities, upload a directory structure for a shared pool, and set up internal structures (e.g. 
various mapping tables). The Administration process 440 also recognizes changes in the 
environment and may handle actions and responses to some of the associated platform 
utilities and commands. 

The basic operation, using the functions outlined above, and the component relationships 
are as illustrated in Fig 4. Upon boot the SAL Administrative process 440 determines that 
only the native drive (103 in Fig 3a) is installed and configured (again, this is the initial 
configuration, prior to adding any new storage elements). It thus sets up, or updates, steering 
tables 451 in the Access Director 450 to recognize disk accesses and send them to the native 
storage element (e.g. Windows C-Drive). In addition, the Administrative process 440 
configures, or sets up, logical volume tables 431 in the Virtual Volume Manager 430 to 
recognize a single, logical drive with the characteristics (size, volume label, etc.) of the 
native drive. In this way the SAL 400 passes storage requests onto the native storage element 
and correctly responds to other storage requests. Once a new drive has been added (17 in Fig 
3a, for example) the Administrative process 440 recognizes this fact (either through 
discovery on boot, or through normal Plug-and-Play type alerts) and takes action. First, the 
Administrative process 440 must query the new drive for its pertinent parameters and 
configuration information (size, type, volume label, location, etc.). This information is then 
kept in an administrative process' Drive Configuration table 441. Secondly, the 
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Administrative process 440 updates the SAL Virtual Volume Manager's logical volume 
tables 431. These tables, one per logical volume, indicate overall size of the merged volume 
as well as any other specific logical volume characteristics. This allows the Virtual Volume 
Manager 430 to respond to various storage requests for read, write, open, size, usage, format, 
compression, etc. as if the system is talking to an actual, physical storage element. Thirdly, 
the Administrative process 440 must update the steering tables 451 in the Access Director 
450. The steering tables 451 allow the Access Director 450 to translate the logical disk 
address (supplied by the File System 310 to the SAL Virtual Volume Manager 430 via the 
File System interface 420) into a physical disk address and send the request to an appropriate 
interface connection process (Network Drive Connection 460 or Disk Driver Connection 470 
in Fig 4). This allows the HSOA volume to be any combination of drive types, locations and 
connectivity methods. The Network Drive Connection 460 or Disk Driver Connection 470 
processes, in turn, package requests in such a manner that a standard driver can be utilized 
(some form of Network Driver 360 or Disk Driver 370 or 373). For the Disk Driver 370 or 
373, this can be a very simple interface and looks like a native File System interface to a 
storage, or disk driver. The Disk Driver Connection 470 must also understand which driver 
and connection to utilize. This information is supplied (as a parameter) in the Access 
Director's 450 command to the Disk Driver Connection process 470. In this example there 
may be one of three storage elements (103, 104, or 17 in Fig 3a) that can be addressed. Each 
storage element may have its own driver and interface. In this example, if the actual data 
resides on the original, native storage element (C-Drive 103 in Fig 3a) the Access Director 
450 and Disk Driver Connection process 470 steer the access to Disk Driver-0 370 and Disk 
Interface-0 371. If the actual data resides on the internal, expansion storage element (Exp 
Drv 104 in Fig 3a) the Access Director 450 and Disk Driver Connection process 470 may 
steer the access, again, to Disk Driver-0 370 and Disk Interface-0 371, or possibly another 
internal driver (if the storage element is of another variety than the native one). If the actual 
data resides on the external, stand-alone expansion Storage Element 17 (Fig 3a) the Access 
Director 450 and Disk Driver Connection 470 may steer the access to Disk Driver-0 370 and 
Disk Interface-1 372. For the Network Driver 360 it's a bit more complicated. Remember, 
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this is all happening below the File System and thus something like a Network File System 
(NFS) or a Common Internet File System (CIFS) are not appropriate. These add far too much 
overhead and require extensive system and user configuration and management. 

OPERATION OF INVENTION - STORAGE EXPANSION AND BASIC STORAGE 
SHARING 

The second major aspect of this invention relates to the addition, and potential sharing 
amongst multiple users, of external intelligent storage subsystems. A simple use of a network 
attached storage device (as opposed to an external stand-alone storage device) is illustrated in 
Fig 2b. This illustrates a single information appliance, or client element 10 connected 9a to a 
Home Network 15, which is, then connected 9d to an intelligent External Storage Subsystem 
16. In this example the expansion is extremely similar to that described in the OPERATION 
OF INVENTION - BASIC STORAGE EXPANSION (above), with the exception that a 
network driver is utilized instead of a disk driver. The basic operation is illustrated in Fig 3b 
and Fig 4. Fig 3b shows an environment wherein the External Storage Subsystem 16 is 
treated like a simple stand-alone device. No other clients, or users, are attached to the storage 
subsystem. Basic client software process relationships are illustrated in Fig 4. Actions and 
operations above the connection processes (Network Driver Connection 460 and Disk Driver 
Connection 470) are described above (OPERATION OF INVENTION - BASIC STORAGE 
EXPANSION). In the case described here, the Access Director 450 interfaces with the 
Network Driver Connection 460. In addition to connecting to the appropriate Network 
Driver 360, the Network Driver Connection 460 provides a very thin encapsulation of the 
storage request that enables, among other things, transport of the request over an external, 
network link and the ability to recognize (as needed) which information appliance (e.g. PC, 
or Hub) sourced the original request to the external device. 

The simple case, where a single External Storage Subsystem 16 is connected to a single 
client, is certainly workable, but not very interesting. Further, the details are encompassed 
within the more complex case outlined next. The power in this sort of environment (external, 
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intelligent storage subsystems) is better represented in Fig 2. In this figure multiple 
information appliance elements (PC Clients 10a and 10b as well as Home Entertainment Hub 
13) are all connected 9a, 9b, and 9c into a Home Network 15, which in turn connects 9d to 
the External Storage Subsystem 16. In this case the External Storage Subsystem 16 is 
intelligent, and is capable of containing multiple disk drives 160a - 160d. This environment 
provides the value of allowing each of the Clients 10a, 10b or Hub elements 13 to share the 
External Storage Subsystem 16. Share, in this instance, implies multiple users for the 
External storage resource, but not sharing of actual data. The methods described in this 
invention provide unique value in this environment. Wherein today's typical Filer must be 
explicitly managed (in addition to setting up the Filer itself, the drives must be mounted by 
the client file system, applications configured to utilize the new storage, and even data 
migrated to ease capacity issues on other drives), this invention outlines a transparent 
methodology to efficiently utilize all of the available storage across all enabled clients. 

The basic, and underlying concept is still an easy and transparent expansion of a client's 
native storage element (e.g. C-Drive in a Windows PC). The OPERATION OF INVENTION 
- BASIC STORAGE EXPANSION section illustrated a single client's C-Drive expansion. 
The difference between this aspect of the invention and that described in the OPERATION 
OF INVENTION - BASIC STORAGE EXPANSION section is that the native storage 
element of each and every enabled Client 10a, 10b, or Hub 13 is transparently expanded, to 
the extent of the available storage in the External Storage Subsystem 16. If the total capacity 
of the External Storage Subsystem 16 is 400 GBytes, then every native drive (not just one 
single drive) of each enabled client 10a, 10b or Hub 13 appears to see an increase in capacity 
of 400 GBytes. 

An alternative is to have each of the native storage elements of each and every enabled client 
10a, 10b, or Hub 13 see a transparently expanded capacity equal to some portion of the total 
capacity of the External Storage Subsystem 16. This may be a desirable methodology in 
some applications. Regardless of the nature, or extent, of the native drive expansion, or the 
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algorithm utilized in dispersing the added capacity amongst enabled clients, the other aspects 
of the invention remain similar. 



All attached users share the entire available capacity of the External Storage Subsystem 16. 
Re-running the Properties command (or something similar) would result in each Client 10a, 
10b, or Hub 13 seeing an increase of available storage space (again, along the lines of the 
example given in the OPERATION OF INVENTION - BASIC STORAGE EXPANSION 
section with Figs 6 and 7). This is extremely powerful. No requirement for a complex NFS or 
CIFS infrastructure (which makes it much easier for simpler elements like Hubs 13 to utilize 
the external storage), no deciding how to configure the storage subsystem, create multiple 
drives to be mounted on the individual clients, or perform complex administrative tasks to 
enable convoluted storage configurations on each Client 10a, 10b, Hub 13 or External 
Storage Subsystem 16. In addition, allowing each client user or hub user to share all of the 
external storage capacity allows much more effective capacity balancing and better 
utilization of the external storage. 

All of this is accomplished with the methods and means outlined in this invention and 
illustrated in Figs 3, 4, 5 and 9. Fig 3 provides a basic overview of the processes and 
interfaces involved in the overall sharing of an External Storage Subsystem 16. Fig 4, which 
has been reviewed in previous discussions, illustrates the processes and interfaces specific to 
a Client 10a, 10b, Hub 13, while Fig 5 illustrates the processes and interfaces specific to 
External Storage Subsystem 16. Fig 3 is the basis for the bulk of this discussion, with 
references to Figs 4 and 5 called out when appropriate. 



Note that for purposes of some brevity in the remaining discussion, no further distinction is 
made between a standard PC Client Element 10a and 10b (Fig 1) and its associated Chassis 
100a and 100b (Figs 1, la, 2, 3, 3c, or 9). Neither is a distinction made between a standard 
PC Client element 10a, 10b and an Entertainment Hub 13, both of which are "client users" of 
the External Storage Subsystem 16. The aggregate of a Client element 10a and 10b (or a 
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Chassis 100a, 100b) and Hub 13 are referred to as information appliances, "HSOA enabled 
clients", or simply "enabled clients". 



When an external, intelligent storage subsystem is added to a home network with HSOA 
enabled clients, the SAL Administration process (440 in Fig 4) of each HSOA enabled client 
is informed of the additional storage by the system processes. An integral part of this 
discovery is the ability of the SAL Administration process (440 in Fig 4) to mask drive 
recognition and usage by the native Operating System (OS), applications, the user, and any 
other low level utilities. One possible method of handling this (in Windows based systems) is 
through the use of a filter driver, or a function of a filter driver, that prevents the attachment 
from being used by the OS. This filter driver is called when the PnP (Plug and Play) system 
sees the drive come on line, and goes out to find the driver (with the filter drivers in the 
stack). While it may not be possible to mask any recognition of the new device by the 
system, the filter driver does not report the device to be in service as a "regular" disk with 
drive designation. This implies that a logical volume drive letter is not in the symbolic link 
table to point to the device and thus is not, available to applications and does not appear in 
any properties information or display. Furthermore, no sort of mount point is created for this 
now unnamed storage element, so the user has no accessibility to this storage. 

Each HSOA enabled client has its logical volume table (431 in Fig 4), its steering table 
(451 in Fig 4) and its drive configuration table (441 in Fig 4) updated to reflect the addition 
of the new storage. Each SAL Administration (440 in Fig 4) may well configure the 
additional storage differently for its HSOA enabled client and SAL processes (400 in Fig 4). 
This may be due to differing size, or number of currently configured drives or differing 
usage. The simplest mechanism is to add the new storage as a logical extension of the current 
storage, and thus any references to storage addresses past the physical end of the current 
drive are directed to the additional storage. For example, this results in the following. If, 
prior to addition of the new storage, Client PC Chassis 100a consists of C-Drive 103a with 
capacity of 15 GBytes and D-Drive 104a with capacity of 20 GBytes; Client PC Chassis 
100b consists of C-Drive 103b with capacity of 30 GBytes; and Hub 13 consists of native 
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drive 103c with capacity of 60 GBytes then the addition of External Storage Subsystem 16 
with a capacity of 400 GBytes results in the following: 

(1) The File System 310a in Chassis 100a sees C-Drive 103a having a capacity of 
15+400, or 41 5 GBytes; 

(2) The File System 310a in Chassis 100a sees D-Drive 104a having a capacity of 
20+400, or 420 GBytes; 

(3) The File System 310b in Chassis 100b sees C-Drive 103b having a capacity of 
30+400, or 430 GBytes; and 

(4) The File System 310c in Hub 13 sees a native drive 103c having a capacity of 
60+400, or 460 GBytes 

In the example above we added a TOTAL of 400 GBytes of extra capacity. While each of the 
HSOA enabled clients can utilize this added capacity, and each of the attached clients new, 
logical drives appear to grow by the entire 400 GBytes they cannot each, in truth, utilize all 
400 GBytes. To do so would imply that we are storing an equivalent of 

415 + 420 + 430 + 460 = 1725 GBytes, or 1.725 TBytes 

This is clearly more capacity than was added. In actuality the added capacity is spread across 
all of the native drives in the environment enabled by the methods described in this 
invention. This method of capacity distribution is clearly not the only possible. There are 
other algorithms (e.g., a certain portion of the overall added capacity could be assigned to 
each native drive - not the entire amount) that could be used but they are immaterial to the 
nature of this invention. 

The SAL processes (400a, 400b and 400c) create these logical drives, or storage objects, 
but the actual usage of the External Storage Subsystem 16 is managed by the SSMS 
processes 500 (Fig 5). As part of the discovery and initial configuration process the SAL 
Administration process (440 in Fig 4) communicates with the SS Administration process 
(530 in Fig 5). Part of this communication is to negotiate for the initial storage partitioning. 
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As illustrated in Fig 9 each attached, HSOA enabled client is allocated some initial space 
(e.g., double space of native drive) 

1 . Drive element 103a (Chassis 100a C-Drive) is allocated 30 GBytes 910 

2. Drive element 104a (Chassis 100a D-Drive) is allocated 40 GBytes 920 

3. Drive element 103b (Chassis 100b C-Drive) is allocated 60 GBytes 930 

4. Drive element 103c (Hub 13 Native-Drive) is allocated 120 GBytes 940 
and some reserved space (typically, 50% of the allocated space) 

1 . Drive element 103a (Chassis 100a C-Drive) is reserved an additional 1 5 GBytes 
911 

2. Drive element 104a (Chassis 100a D-Drive) is reserved an additional 20 GBytes 
921 

3. Drive element 103b (Chassis 100b C-Drive) is reserved an additional 30 GBytes 
931 

4. Drive element 103c (Hub 13 Native-Drive) is reserved an additional 60 GBytes 
941 

by the SS Administration process (530 in Fig 5). Again, this allocation is only an example. 
Many alternative allocations are possible and fully supported by this invention. At a very 
generic level (not using actual storage block addressing) this results in the following for 
client 100a in Fig 3. The Virtual Volume manager (430 in Fig 4) has two logical volume 
tables (431 in Fig 4), Logical-C and Logical-D, representing the two logical volumes. The 
Access Director (450 in Fig 4) has two steering tables (451 in Fig 4) configured as shown in 
Tables I and II. 



Table I 

Steering Table - Logical C-Drive 


Logical Address Range 
(word = 4 bytes) 


Drive 


Interface 


Actual/Physical 
Drive Address 


Notes/Actions 


1-3,750,000,000 


C 


DiskO 


1 - 

3,750,000,000 


Access Native Drive 


3,750,000,001 - 12,500,000,000 


Ext SS 


Network 


1 - 

7,500,000,000 


Access External Storage Subsystem 


12,500,000,001 - 15,000,000,000 


Ext SS 


Network 


7,500,000,001 - 


Using up the reserved area, have 
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11 ,250,000,000 


Administration process increase 
reserve space 


1 5,000,000,00 1 - max address 


NA 


NA 


ERROR 


Error, has to be handled as an out 
of bounds condition 




Table II « 
Steering Table - Logical D-Drive 


Logical Address Range 
(Word=4 bytes) 


Drive 


Interface 


Actual/Physical 
Drive Address 


Notes/Actions 


1-5,000,000,000 


D 


DiskO 


1- 

5,000,000,000 


Access Native Drive 


5,000,000,001 - 15,000,000,000 


ExtSS 


Network 


11,250,000,001- 
21,250,000,000 


Access External Storage 
Subsystem 


15,000,000,001 -20,000,000,000 


Ext SS 


Network 


21,250,000,001 - 
26,250,000,000 


Using up the reserved area, 
have Administration process 
increase reserve space 


20,000,000,001 - max address 


NA 


NA 


ERROR 


Error, has to be handled as an 
out of bounds condition 



Once the basic tables are set up, HSOA enabled client operations proceed in a manner 
similar to that described previously. The SAL File System Interface process (420 in Fig 4) 
intercepts all storage element requests. These pass on to the SAL Virtual Volume Manager 
process (430 in Fig 4) that, through use if its logical volume tables, either responds to the 
request directly (a volume size query, for example) or passes the request on to the Access 
Director process (450 in Fig 4). Requests that pass on to the Access Director 450 imply that 
the actual device is accessed (typically a read or a write). The Access Director 450, through 
use of its steering tables (451 in Fig 4), dissects the logical volume request and determines 
which physical volume to address and what block address to utilize. 

In the case in hand (the environment illustrated in Fig 3 with the External Storage 

Subsystem 16, encompassing an additional 400 GBytes of storage capacity, configured as an 

extension to the internal disk drives 103a, 103b, 103c, and 104a, as outlined above), assume 

that the client represented by PC chassis 100a is accessing its logical C-drive at address 

6,000,000,000 (word address, with a word consisting of 4 bytes). In an actual environment 

addressing methodologies can vary, these addresses are simply used to convey the 

mechanisms and processes involved. The SAL Virtual Volume Manager process (430 in Fig 
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4) determines that this is a read/write operation for its logical C-drive. This is passed along to 
the Access Director (450 in Fig 4). The Access Director 450 utilizes its steering table (451 in 
Fig 4, and Table I above) to determine how to handle the request. The logical disk address is 
used as an index entry into the table (e.g. using the Logical Address Range column in Table 
I). This will then indicate that the External Storage Subsystem 16 must be accessed, using the 
Network Driver (360 in Fig 4). The table indicates the appropriate driver, if more than one 
exists, and the adjusted address. In this case a local address 6,000,000,000 maps to remote 
address of 2,250,000,000. Once this determination is made, the Access Director 450 passes 
the request to the appropriate connection process, in this case the Network Connection 
process (460 in Fig 4). The connection process then appropriately packages, or encapsulates 
the request such that it passes to the correct standard Network Driver (360 in Fig 4) that, in 
turn, accesses the device. In this case the device is an intelligent External Storage Subsystem 
16 with processes and interfaces illustrated in Fig 5. The HSOA enabled client request is 
picked up by the External Storage Subsystem's 16 Network Interface 361 and Network 
Driver 360. These are similar (if not identical) to those of a client system. A Storage 
Subsystem (SS) Network Driver Connection 510 provides an interface between the standard 
Network Driver 360 and a SS Storage Client Manager 520. The SS Network Driver 
Connection process 510 is, in part, a mirror image of an enabled client's Network Driver 
connection process (460 in Fig 4). It knows how to pull apart the network packet to extract 
the storage request, as well as how to encapsulate responses, or requests, back to an enabled 
client. In this example the SS Network Driver Connection 510 extracts the read/write request 
to address 2,250,000,000 on the external storage portion of the logical volume. The SS 
Storage Client Manager 520 is cognizant of which enabled client machine is accessing the 
storage subsystem and tags commands in such a way as to ensure correct response return.. 
The SS Storage Client Manager 520 translates specific client requests into actions for a 
specific logical storage subsystem volume(s) and passes requests on to a SS Storage Volume 
Manager 540, or to a SS Administration 530. In this example, since the request is a simple 
read/write for a valid address, there are no triggers for any sort of expansion operation (see 
below); the command passes along to the SS Volume Manager 540. The SS Volume 
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Manager 540 may be a fairly standard volume manager process. It knows how to take the 
logical volume commands from the client SAL Virtual Volume Manager (430 in Fig 4) and 
translate into appropriate commands for specific drive(s). The SS Volume Manager 540 
process handles any logical drive constructs (Mirrors, RAID, etc. . .) implemented within the 
External Storage Subsystem 16. The SS Volume Manager 540 then passes along the 
command to the SS Disk Driver Connection 560 that, in turn, passes the command to the 
Disk Driver 370 for issuance to the actual drive. A read command returns data from the drive 
(along with other appropriate responses) to the client, while a write command would send 
data to the drive (again, ensuring appropriate response back to the initiating client). Ensuring 
that the request is sent back to the correct client is the responsibility of the SS Client 
Manager process 520. The SS Administration 530 handles any administrative requests for 
initialization and setup. The SS Administration process 530 may have a user interface (a 
Graphical User Interface, or a command line interface) in addition to several internal 
software automation processes to control operation. The SS Administration process 530 
knows how to recognize and report state changes (added/removed drives) to appropriate 
clients and handles expansion, or contraction, of any particular client's assigned storage area. 
Any access made to a client's reserved storage area is a trigger for the SS Administration 
process 530 that more storage space is required. If un-allocated space exists this will be 
added to the particular client's pool (with the appropriate External Storage Subsystem 16 and 
HSOA enabled client tables updated). 

The same, or very similar, administrative processes are used to transparently add storage 
to the External Storage Subsystem 16. When an additional storage element is added the SS 
Administration process 530 recognizes this. The SS Administration process 530 then adds 
this to the available storage pool (un-reserved and un-allocated), communicates this to the 
SAL Administration processes 440 and all enabled clients may see the expanded storage. 

An External Storage Subsystem 16 may be enabled with the entire SS process stack or an 
existing intelligent subsystem may only add the SS Network Driver Connection 510, SS 
Client Manager 520 and SS Administration 530 processes in conjunction with a standard 
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volume manager (et al). In this way the current invention can be used with an existing 
intelligent storage subsystem or one can be built with all of the processes outlined above. 

OPERATION OF INVENTION - EXPANSION AND DATA SHARING 

The third aspect of the current invention incorporates the ability for multiple information 
appliances to share data areas on shared storage devices or pools. In both of the previous 
examples, each of the HSOA enabled clients treated their logical volumes as their own 
private storage. No enabled client could see nor access the data or data area of any other 
enabled client. In these previous examples storage devices may be shared, but data is private. 
Enabling a sharing of data and storage is a critical element in any truly networked 
environment. This allows data created, or captured, on one client, or information appliance to 
be utilized on another within the same networked environment. 

Currently, a typically deployed intelligent computing system utilizes a network file 
system tool (NFS or CIFS are most common) to facilitate the attachment and sharing of 
external storage. Many issues (see BACKGROUND OF THE INVENTION) arise with this 
mechanism. Even though the storage subsystem, and even some data, is shared, it's neither 
easily expandable nor manageable. In all cases the added storage is recognized as a separate 
drive element or mount point and must be managed separately. 

Figs 4, 4b and 8 are utilized to illustrate an embodiment of a true, shared storage and data 
environment wherein the previously described aspects of transparent expansion of an existing 
native drive are achieved. This example environment contains a pair of information 
appliances, the local client 800a and the remote client 800b. Fig 8 differs from Figs 3a and 4 
in that the simple, single File System (310 in Figs 3a and 4) has been expanded. The Local 
FS 310a, 310b in Fig 8 is equivalent to the File System 310 in these previous figures. In 
addition to the Local FS 310a, 310b a pair of new file systems (or file system access drivers) 
850a, 860a, 850b, 860b have been added, along with an IO Manager 840a, 840b. These 
represent examples of native system components commonly found on platforms that support 
CIFS. The IO Manager 840a, 840b directs Client App 810a, 810b requests to the Redirector 
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FS 850a, 850b or to the Local FS 310a, 310b, depending upon the desired access of the 
application or user request; local device or remotely mounted device The Redirector FS is 
used to access a shared storage device (typically remote, but not required) and works in 
conjunction with the Server FS 860a, 860b to handle locking and other aspects required to 
share data amongst multiple clients. In systems without the HSOA enabled clients the 
Redirector FS communicates with the Server FS through a Network File Sharing protocol 
(e.g. NFS or CIFS). This communication is represented by the Protocol Drvr 880a, 880b and 
the bi-directional links 820, 890a and 890b. In this way a remote device may be mounted on 
a local client system, as a separate storage element, and data are shared between the two 
clients. In this embodiment the HSOA SAL Layer (as described in the previous sections) is 
again inserted between the Local FS 310a, 310b and the drivers (Network 360a, 360b and 
Disk 370a, 370b). In addition, a new software process is added. This is the HSOA Shared 
SAL (SSAL) 870a, 870b and it is layered between the Redirector FS 850a, 850b and the 
Protocol Drvr 880a, 880b. 

For this example a single disk device 103b is directly (or indirectly) added to the remote 
client 800b. Directly added means an internal disk, such as an IDE disk added to an internal 
cable, indirectly added means an external disk, such as a USB attached disk. Further, for this 
example, the device 103b, and any data contained on it are to be shared amongst both clients 9 
800a, 800b. Thus thru the methods and processes of the current invention the Local Client 
800a sees an expanded, logical drive 105a which has a capacity equivalent to its Native 
Device 104a + the remote Exp Device 103b. In addition, the contents of the expanded, 
logical drive 105a that reside on Native Device 104a are private (can be written and read 
only by the local client 800a) while the contents of the expanded, logical drive 105a that 
reside on Exp Drive 103b are shared (can be read/written by both the Local Client 800a and 
the Remote Client 800b). Finally the Remote Client 800b also sees an expanded, logical 
drive 105b which has a capacity equivalent to its Native Device 104b + the local Exp Device 
103b. In addition, the contents of the expanded, logical drive 105b that reside on Native 
Device 104b are private (can be written and read only by the local client 800b) while the 
contents of the expanded, logical drive 105b that reside on Exp Drive 103b are shared (can 
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be read/written by both the Local Client 800a and the Remote Client 800b). Recall that one 
of the parameters of this example is that the data on Exp Device 103b are sharable. Thus 
each client 800a, 800b has private access to its original native storage device 104a, 104b 
contents and shared access to the Exp Device 103b contents. Although neither client 800a, 
800b has any capability to deconstruct its particular expanded drive 105a, 105b. 

In this aspect of the current invention the SAL Administration processes 440 (Fig 4) of 
each of the client systems has an added capability. They are able to communicate with each 
other (an extension of previously describe initialization and configuration steps) through the 
Network Dvr Connection (460 in Fig 4). When the Expansion Drive 103b is added into 
Remote Client 800b the SAL Administration process (440 in Fig 4) local to that SAL Layer 
310b does several things upon recognition of the new device. First, it masks recognition of 
the device from the system (as described in previous examples above). Second, it queries the 
device for its specific parameters (e.g. type, size, . . .). Third, through either defaults, or user 
interaction/command it determines if this device 103b is shared or private (or some aspects 
of both). If it's private, then the device 103b is treated as a normal HSOA added device and 
expansion of the Native Device 104b into the logical device 105b is accomplished as 
described above (refer to the section - OPERATION OF INVENTION - BASIC STORAGE 
EXPANSION). And, no part of the drive would be available to Local Client 800a for 
expansion. If the Expansion Device 103b is to be shared, the SAL Administration process 
(440 in Fig 4) local to that SAL Layer 310b will take the following steps: 

(1) An expanded, logical device 105b is created (see OPERATION OF INVENTION - 
BASIC STORAGE EXPANSION section for details on creation of this expanded logical 
device) as a combination of the Native Device 104b and the Exp Device 103b. Since the 
Native Device 104b is already known to the LOCAL FS 310b, and the expanded device 
105b is simply an expansion, the IO Manager 840b is set to forward any accesses to the 
Local FS 310b 

(2) The availability of the Exp Device 103b and the new logical device 105b are 
broadcast such that any other HSOA Admin layer (in this case the SAL Administration 
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process (440 in Fig 4) associated with HSOA SAL Layer 400a) is notified of the existence of 
the Exp Device 103b, and the new logical device 105b along with their access paths and 
specific parameters. This can be accomplished through use of a mechanism like the Universal 
Plug and Play (UPnP) or some other communication mechanism between the various HSOA 
Admin processes. 

(3) The HSOA Virtual Volume table(s) (431 in Fig 4) associated with SAL Layer 310b is 
set to indicate that any remote access to addresses ranges corresponding to the Native Device 
104b are blocked (i.e. are kept private), while any remote access to addresses ranges 
corresponding to the Exp Device 103b are allowed. 

In addition, the SAL Administration process (440 in Fig 4) local to that SAL Layer 310a will 
take the following steps: 

(1) An expanded, logical device 105a is created (see OPERATION OF INVENTION - 
BASIC STORAGE EXPANSION section for details on creation of this expanded logical 
device) as a combination of the Native Device 104a and the remote Exp Device 103b. 

(2) The IO Manager 840a in the Local Client 800a is set to recognize the expanded 
logical device 105a and to forward any accesses via the Redirector FS 850a and not the 
Local FS 310a. The now-expanded volume appears to be a network attached device, no 
longer a local device. Note, the Local FS 310a remains aware of this logical device 105a to 
facilitate accesses via the Server FS 860a, it's simply that all requests are forced through the 
Redirector 850a and Server FS 860a path. 

(3) The HSOA Virtual Volume table(s) (431 in Fig 4) associated with SAL Layer 400a 
are set to indicate that any remote access to addresses ranges corresponding to the Native 
Device 104a are blocked, while any remote access to addresses ranges corresponding to the 
Exp Device 103b are allowed. Note, this is simply a precaution as any "remote" access to 
Exp Device 103b would be directed to the Local FS 310b by the IO Manager 840b and not 
across to the Local Client 800a. 
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(4) The HSOA SSAL layer 870a is set to map accesses to addresses ranges, file handles, 
volume labels or any combination thereof corresponding to the Native Device 104a to the 
local Server FS 860a with logical drive parameters matching 105a, while any access to 
addresses ranges, file handles, volume labels or any combination thereof corresponding to the 
Exp Device 103b are mapped to the remote Server FS 860b with logical drive parameters 
matching 105b. In this way the various logical drive 105a accesses are mapped to drives 
recognized by the corresponding Local FS 310a, 310b and HSOA SAL Layer 400a, 400b. 

} 

Any and all subsequent accesses (e.g. reads and writes) to the Local Client's 800a logical 
drive 105a are sent (by the IO Manager 840a) to the Redirector FS 850a. The Redirector FS 
850a packages this request for what it believes to be a shared network drive. The Redirector 
FS 850a works in conjunction with the Sever FS 860a, 860b to handle the appropriate file 
locking mechanisms which allow shared access. Communication between Redirector FS 
850a and Server FS 860a, 860b are done via the Protocol Drvrs 880a, 880b. Commands sent 
to the Protocol Drvr 880a are filtered by the HSOA SSAL processes 870a. The HSOA 
SSAL 870a processes are diagramed in Fig 4b. The SSAL File System Intf 872 intercepts 
any communication intended for the Protocol Drvr 870a and packages it for use by the SSAL 
Access Director 874. By re-packaging, as needed, the SSAL File System Intf 872 allows the 
HSOA SSAL processes 870 to be used with a variant of redirector/server FS types (e.g. 
Windows, Unix, Linux). The SSAL Access Director 874 utilizes its Access Director table 
(SSAL AD Table 876) to steer the access to the appropriate Server FS 860a, 860b. This is 
done by inspecting the block address, file handle, volume label or a combination thereof in 
the access request to determine if the access is intended for the local Native Device 104a or 
the remote Exp Device 103b. Once this determination has been made the request is updated 
as follows: 

• The IP address of the appropriate Server FS (Local Client 800a or Remote Client 
800b) is inserted. This ensures that the command is sent to the correct client. 
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• The Volume label, file handle, block address or a combination thereof are updated 
to reflect the actual Local FS 310a, 310b aware volume parameters: 

o If an access is intended for the logical volume 105a as a whole (e.g. some 
form of volume query) then the access is pointed to logical volume 105a 
through the local Sever FS 860a 

o If an access is intended to read/write (or in some way modify data or 
content) the physical Native Device 104a then the access is pointed to 
logical volume 105a through the local Sever FS 860a 

o If an access is intended to read/write (or in some way modify data or 

content) the physical Exp Device 103b then the access is pointed to logical 
volume 105b through the Remote Client 800b Sever FS 860b 

Once these basic parameters have been established the access request, or command is passed 
to the Protocol Drvr 880a through the Protocol Drvr Connection 878. The Protocol Drvr 
Connection 878 allows the allows the HSOA SSAL processes 870 to be used with a variant 
of redirector/server FS types (e.g. Windows, Unix, Linux) as well as a variant of Network 
File access protocols (e.g. CIFS and NFS). Accesses through the Sever FS 860a, 860b and 
the Local FS 310a, 310b are dictated by normal OS operations and access to the actual 
devices are outlined in the above section (see OPERATION OF INVENTION - BASIC 
STORAGE EXPANSION). Upon return through the Protocol Drvr 880a, the Protocol Drvr 
Connection 878 will intercept, and package the request response for the SSAL Access 
Director 874. The SSAL Access Director 874 reformats the response to align with the 
original request parameters and passes the response back to the Redirector FS 850a through 
the SSAL File System Intf 872. 

An alternative embodiment is illustrated using Figs 4c and 8a This example environment 
contains a pair of information appliances, the local client 800a and the remote client 800b. 
For simplified discussion and diagram purposes the Local Client 800a can mount a remote 
volume served by Remote Client 800b. In everyday practice both the Local Client 800a and 
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the Remote Client 800b can mount logical volumes on one another, and thus both can be 
servers to the other, and both can have the Redirector and Server methods. 

In comparison with Fig 3a, Fig 8a shows typical information appliance methods. The 
Client Application 810a, 810b executing in a non-privileged "user mode" makes file requests 
of the 10 Manager 840a, 840b running in privileged "Kernel mode." The IO Manger 840a, 
840b directs a file request to either a Local File System 310a, 310b, or in the case of a 
request to a remotely mounted device, to the Redirector FS 850a. The Redirector FS 850a is 
a standard network file system protocol to facilitate the attachment and sharing of remote 
storage. The Redirector FS 850a communicates with the remote Server FS 860b through a 
Network File Sharing protocol (e.g. NFS or CIFS). This communication is represented by the 
Protocol Drvr 880a, 880b and the bi-directional link 820. In this way a remote device may be 
mounted on a local client system as a separate storage element, and data are shared between 
the two clients. 

In this embodiment an HSOA SAL Layer 400a, Fig 4c, (as described in the previous 
sections) is again inserted between the Local FS 310a, 310b and the drivers (Network 360a, 
360b and Disk 370a, 370b). In this aspect of the invention, the HSOA SAL Layer 400a has 
an additional component, the Redirector Connection 490. This allows the SAL Access 
Director 450, Fig 4c, the added option of sending a request to the Redirector Driver 391. 

For this example a single disk device 103b is directly (or indirectly) added to the remote 
client 800b. Directly added means an internal disk, such as an IDE disk added to an internal 
cable, indirectly added means an external disk, such as a USB attached disk. Further, for this 
example, the device 103b, and any data contained on it are to be shared amongst both clients' 
800a, 800b. Thus thru the methods and processes of the current invention the Local Client 
800a sees an expanded, logical drive 105a which has a capacity equivalent to its Native 
Device 104a + the remote Exp Device 103b. In addition, the contents of the expanded, 
logical drive 105a that reside on Native Device 104a are private (can be written and read 
only by the local client 800a) while the contents of the expanded, logical drive 105a that 
reside on Exp Drive 103b are shared (can be read/written by both the Local Client 800a and 
the Remote Client 800b). The Remote Client 800b also sees an expanded, logical drive 105b 
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which has a capacity equivalent to its Native Device 104b + the local Exp Device 103b. In 
addition, the contents of the expanded, logical drive 105b that reside on Native Device 104b 
are private (can be written and read only by the local client 800b) while the contents of the 
expanded, logical drive 105b that reside on Exp Drive 103b are shared (can be read/written 
by both the Local Client 800a and the Remote Client 800b). Recall that a parameter of this 
example is that the data on Exp Device 103b are sharable. Thus each client 800a, 800b has 
private access to its original native storage device 104a, 104b contents and shared access to 
the Exp Device 103b contents. Although neither client 800a, 800b has any capability to 
deconstruct its particular expanded drive 105a, 105b, in keeping with the basic methods of 
the current invention. 

In this aspect of the current invention the SAL Administration processes 440 (Fig 4c) of 
each of the client systems has an added capability. They are able to communicate with each 
other (an extension of previously describe initialization and configuration steps) through the 
Network Dvr Connection (460 in Fig 4c). When the Expansion Drive 103b is added into 
Remote Client 800b the SAL Administration process (440 in Fig 4c) local to that SAL Layer 
310b does several things upon recognition of the new device. First, it masks recognition of 
the device from the system (as described in previous examples above). Second, it queries the 
device for its specific parameters (e.g. type, size, ...). Third, through either defaults, or user 
interaction/command it determines if this device 103b is shared or private (or some aspects 
of both). If it is private, then the device 103b is treated as a normal HSOA added device and 
expansion of the Native Device 104b into the logical device 105b is accomplished as 
described above (refer to the section - OPERATION OF INVENTION - BASIC STORAGE 
EXPANSION). And, no part of the drive would be available to Local Client 800a for 
expansion. If the Expansion Device 103b is to be shared, the SAL Administration process 
(440 in Fig 4c) local to that SAL Layer 310b takes the following steps: 

(4) An expanded, logical device 105b is created (see OPERATION OF INVENTION - 
BASIC STORAGE EXPANSION section for details on creation of this expanded logical 
device) as a combination of the Native Device 104b and the Exp Device 103b. 
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(5) The availability of the shared Exp Device 103b and parameters about the new logical 
device 105b are broadcast such that they are received any other HSOA Admin layer (in this 
case the SAL Administration process (440 in Fig 4c) associated with HSOA SAL Layer 
400a). Notification information includes the existence of the Exp Device 103b, and the new 
logical device 105b along with their access paths (IP address for example and any other 
specific identifier) and specific parameters, such as private address ranges on the newly 

s expanded remote device 105a. This is accomplished through use of a mechanism like the 

Universal Plug and Play (UPnP) or some other communication mechanism between the 
various HSOA Admin processes. 

(6) The HSOA Virtual Volume table(s) (431 in Fig 4c) associated with SAL Layer 310b 
is set to indicate that any remote access to addresses ranges corresponding to the Native 
Device 104b are blocked (i.e. are kept private), while any remote access to addresses ranges 
corresponding to the Exp Device 103b are allowed. 

On the Local Client 800a, the SAL Administration process (440 in Fig 4c) local to that 
SAL Layer 310a takes the following steps: 

(5) An expanded, logical device 105a is created (see OPERATION OF INVENTION - 
BASIC STORAGE EXPANSION section for details on creation of this expanded logical 
device) as a combination of the Native Device 104a and the remote Exp Device 103b. 

(6) The HSOA Virtual Volume table(s) (431 in Fig 4c) associated with SAL Layer 400a 
are set to indicate that any access from a remote client to addresses ranges corresponding to 
the Native Device 104a are blocked, while any remote access to addresses ranges 
corresponding to the Exp Device 103b are allowed. This keeps 104a contents private. 

(7) The HSOA Virtual Volume table(s) (431 in Fig 4c) associated with SAL Layer 400a 
are set to indicate that any access to addresses corresponding to Exp Device 103b are sent out 
the Redirector Connection 490 and on to the Redirector Driver 391 . 
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A file request from the Client Application 810a proceeds to the 10 Manager 840a, which 
can choose to send it directly to the Redirector FS 850a if the destination device is remotely 
mounted directly to the information appliance. Or, the 10 Manager can choose to send the 
request to the Local FS 310a. In our example the request goes to the Local FS 310a, and is 
destined for an expanded device 105a. The SAL Access Director 450 (Fig 4c), which 
resides within the HSOA SAL Layer 400a processes, determines the path of the request If 
the accessed address is on the original native Device 104a the request proceeds to the Disk 
Drvr370a. 

If the accessed address is on Exp Device 103b, the SAL Access Director 450 adjusts the 
address, using its knowledge of the remote expanded volume 105b, so that the address 
accounts for the size of the remote Native Device 104b. (Recall that information on the 
expanded device 105b was relayed when it was created.) The SAL Access Director 450a 
then routes the request to the Redirector Connection 490 (Fig 4c), which forms the request, 
specifying a return path to the Redirector Connection 490 and passes the request to the 
Redirector Driver 391, which in turns passes the request to the Redirector FS 850a. The 
request is sent by the standard system Redirector FS 850a through the Protocol Drvr 880a, 
across the communication path to the Remote Client 800b Protocol Driver 880b. (There are 
standard network connections and interactions as used by the protocol implied by the 
Protocol Drvr 880a.) The Server FS 860a on the Remote Client 800b get the request and 
performs any file lock checking. The Server FS 860a then passes the request on to the Local 
FS 310b, which accesses its expanded device 105b through the HSOA SAL Layer 400b. 
The data are accessed and returned via the reverse path and returned to the Redirector 
Connection 490 (Fig 4c) within the Local Client 800a HSOA SAL layer. The return path 
goes from the HSOA SAL Layer 400a back through the Local FS 310a, the IO Manger 840a, 
and to the Client Application 810a. By routing the access to the standard Redirector FS 850a, 
and using a standard file system protocol, file-locking mechanisms are inherent when 
accessing the data on the Exp Device 103b. 

The above descriptions outline how new, logical volumes are created (again, masking the 
underlying physical devices and simply, transparently presenting larger logical devices to the 
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file systems) and data within them can be shared amongst multiple clients. This differs from 
current mechanisms were the Exp Device 103b would be mounted and visible on both 
Clients, but separate from the Native devices 104a, 104b. 

OPERATION OF INVENTION -CLIENT-ATTACHED STORAGE ELEMENT SHARING 

The fourth aspect of the current invention is the ability of one client to utilize storage 
attached to another client. (This is storage element sharing, but not data sharing.) Such 
attached storage may be internal, such as a storage element attached to an internal cable. Or, 
the attached storage may be externally attached; such as a wireless connection, a Firewire 
connection, or a network connection. Figs 3 and 4a demonstrate the methods of this aspect of 
the current invention. While extensible to any attached storage element, this example uses 
Hub 13 and Chassis 2 100b (Fig 3). In this example Hub 13 is allowed to utilize an 
Expansion Drive 104b in Chassis 2 100b as additional storage. This is a very real life 
situation. Many home environments contain both Entertainment Hubs and PCs and the ability 
to utilize storage of one to expand the storage of another is extremely advantageous. 

In this aspect of the current invention the SAL Administration processes 440 (Fig 4a) of 
each of the client systems (Chassis 2 100b and Hub 13) are able to communicate with each 
other through the Network Dvr Connection (460 in Fig 4a). When the Expansion Drive 104b 
is added into Chassis 100b the SAL Administration process 440 local to Chassis 2 100b 
again (as described in previous examples above) masks the recognition of this drive from the 
OS and FS. The SAL Administration process 440 (Fig 4b) that resides within the SAL 
Processes 400b in Chassis 100b then broadcasts (over Home Network 15) the fact that 
another sharable drive is now present in the environment. Any system enabled with the 
HSOA software can take advantage of this added storage (including the system into which 
the storage is added). For the Hub 13, usage is identical to that outlined in the previous 
sections, where externally available network storage accesses are discussed. The SAL 
Administration process 440, Fig 4a, (residing within SAL Processes 400c) in the Hub 13 
updates its local logical volume table(s) 431 and the steering table 451 such that accesses 
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beyond the boundary of the local native drive element 103c are directed towards the 
Expansion drive 104b in Chassis 100b. Again, these are the same processes and steps utilized 
for the external shared storage access and usage model outlined in the previous section (see 
OPERATION OF INVENTION - BASIC STORAGE EXPANSION). For the Chassis 100b, 
Fig 4a is used to illustrate the SAL processes required to share its Exp Drive 104b. The SAL 
Administration process 440 sets up the Access Director 450 and the Network Driver 
Connection process 460 to handle incoming storage requests (previous descriptions simply 
provided the ability for the Access Director 450 to receive requests from its local Virtual 
Volume Manager 430). In this embodiment of the invention, the Access Director 450 
(associated SAL Processes 400b within Chassis 2 100b in Fig 3) now accepts requests from 
remote SAL Processes (400c in Fig 3). The SAL Administration 440 and Access Director 
450 act in a manner similar to that described for the SS Administration (530 in Fig 5) and SS 
Client Manager (520 in Fig 5). In fact, one method of implementation is to add a SAL Client 
Manager process 480 (similar to the SS Client Manager) into the SAL process stack 400, as 
illustrated in Fig 4a. While other implementations are certainly possible (including modifying 
the Access Director 450 and Network Driver Connection 460 to adopt these functions) the 
focus of this example is as illustrated in Fig 4a. As shown in Fig 4a the local Access Director 
450 still has direct paths to the local Disk Driver Connection 470 and Network Driver 
Connection 460. However, a new path is added wherein the Access Director 450 may now 
also steer a storage access through a SAL Client Manager 480. Thus the Access Director's 
450 steering table 451 can direct an access directly to a local disk, through the Disk Driver 
Connection 470; to a remote storage element, through the Network Driver Connection 460; 
or to a shared internal disk through the SAL Client Manager 480. The SAL Administration 
process 440 is shown with an interface to the SAL Virtual Volume Manager 430, the Access 
Director 450 and the SAL Client Manager 480. As described previously, the SAL 
Administration process 440 is responsible for initialization of all the tables and configuration 
information in the other local processes. In addition, the SAL Administration process 440 is 
responsible for communicating local storage changes to other HSOA enabled clients (in a 
manner similar to the SS Administration process, 530 in Fig 5) and updating the local tables 
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when a change in configuration occurs (locally, or remotely). The SAL Client Manager 480 
acts in much the same way as the SS Client Manager (520 in Fig 5) and described earlier. An 
access, for the local storage, is received from either the local Access Director 450 (without 
the intervening Network transport mechanisms) or from the Access Director of a remote SAL 
Process (400c in Fig 3), through the Network Driver 360 and Network Driver Connection 
460. Again, similar to the description above, the Client Manager 480 is cognizant of which 
client machine is accessing the storage (and will tag commands in such a way as to ensure 
correct response return). The Client Manager 480 translates these specific client requests 
into actions for a specific local disk volume(s) and passes them to the Disk Driver 
Connection 470 or to the Admin process 440. There is no volume manager process in this 
example as no intent exists to support complex logical volumes in this example. While this is 
certainly possible, and a storage volume manager could be added to this concept, this simpler 
example is provided. Thus the added drive (104b in Fig 3) can be partitioned in a manner 
similar to that shown in Fig 9 and thus shared amongst any HSOA enabled client in the 
environment. 

The advantages of this ability to share access to attached storage devices are many. A few 
are outlined below: 

(1) Other clients 10a, 10b, or Hubs 13 (Fig 3) in an HSOA enabled environment can 
quite easily access and share any storage in the environment without modifications to any 
File System, Utility, Application or OS. All storage in the environment can be treated as part 
of a common pool, or Object of which all clients may take advantage. 

(2) When any enabled client is added to the environment (or an existing client is 
upgraded with the HSOA software) it can automatically participate and take advantage of all 
the available storage. This can be handled through use of a mechanism like the Universal 
Plug and Play (UPnP) or some other communication mechanism between the various HSOA 
Admin processes 

(3) This is not just a "lower cost NAS box for the home". This starts as simply a 
storage/object device on the local HAN (Home Area Network) but can expand to wider area 
connectivity (not necessarily a larger numbers of servers, but wider geographical area in 
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which to address storage - Internet storage backups, or addressable movie vaults, etc.) and 
thus almost infinite access to data. 

Through the various mechanisms and embodiments described above (BASIC STORAGE 
EXPANSION, EXPANSION AND BASIC STORAGE SHARING, EXPANSION AND 
DATA SHARING and CLIENT- ATTACHED STORAGE ELEMENT SHARING) a true 
bridge is provided between Information Appliances (e.g. the Home entertainment center 
network/equipment and the Home PC network and equipment). What is common to all 
Information Appliances is the data, and this is what really wants to be shared. In addition, the 
groundwork is provided to support a truly distributed, commodity based home computing, 
network and entertainment infrastructure. In this paradigm all physical components have an 
extremely short useful life. In a matter of months or a few short years the infrastructure is 
obsolete. The one lasting aspect of the entire model is the data. The data is the only thing that 
has long-term value and must be retained. By providing a sharable, virtual and external 
storage concept we provide the ability for a user to retain data while upgrading other 
infrastructure elements to meet any future needs. 
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DESCRIPTION AND OPERATION OF ALTERNATIVE EMBODIMENTS 

Fig 3c illustrates another possible embodiment of the current invention. In this instance 
an intelligent External Storage Subsystem 16 is connected 20, 21 and 22 to any enabled 
HSOA client (one, or more) 100a, 100b, or 13 through a storage interface as opposed to a 
network interface. In this case the SAL Processes 400a, 400b and 400c utilize a Disk Driver 
370a, 370b, and 370c and corresponding standard Disk Interface 372a, 372b, 372c to 
facilitate connectivity to the intelligent External Storage Subsystem 16. The nature and 
specific type of standard storage interconnect (e.g. Fire Wire, USB, SCSI, FC, . ..) is 
immaterial. Operation of this particular embodiment is similar to that described in the 
OPERATION OF INVENTION - STORAGE EXPANSION AND BASIC SHARING (see 
earlier section of this document) and the following description assumes that any relevant 
aspects of that embodiment are understood and included in this alternative. The differences 
are illustrated below. 

Using Fig 5a (with Figs 3c and 4 referenced when necessary) the operation of this 
alternative embodiment is summarized. When an external, intelligent storage subsystem is 
added to a home network with HSOA enabled clients, the SAL Administration process (440 
in Fig 4) of each HSOA enabled client is informed of the additional storage by the system 
processes. Each HSOA enabled client has its logical volume table (431 in Fig 4), its steering 
table (451 in Fig 4) and its drive configuration table (441 in Fig 4) updated to reflect the 
addition of the new storage. The simplest mechanism is to add the new storage as a logical 
extension of the current storage, and thus any references to storage addresses past the 
physical end of the current drive are directed to the additional storage. For example, this 
results in the following. Looking at Fig 3c, if, prior to addition of the new storage, Client PC 
Chassis 100a consists of C-Drive 103a with capacity of 15 GBytes and D-Drive 104a with 
capacity of 20 GBytes; Client PC Chassis 100b consists of C-Drive 103b with capacity of 30 
GBytes; and Hub 13 consists of native drive 103c with capacity of 60 GBytes then the 
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addition of External Storage Subsystem 16 with a capacity of 400 GBytes results in the 
following: 

(1) The File System 310a in Chassis 100a sees C-Drive 103a having a capacity of 
15+400, or 415 GBytes; 

(2) The File System 310a in Chassis 100a sees D-Drive 104a having a capacity of 
2(H-400, or 420 GBytes; 

(3) The File System 310b in Chassis 100b sees C-Drive 103b having a capacity of 
30+400, or 430 GBytes; and 

(4) The File System 310c in Hub 13 sees a native drive 103c having a capacity of 
60+400, or 460 GBytes 

In the example above we added a TOTAL of 400 GBytes of extra capacity. While each of the 
HSOA enabled clients can utilize this added capacity, and each of the attached clients new, 
logical drives appear to grow by the entire 400 GBytes they cannot each, in truth, utilize all 
400 GBytes. To do so would imply that we are storing an equivalent of 

415 + 420 + 430 + 460 = 1725 GBytes, or 1.725 TBytes 

This is, clearly, more capacity than was added. In actuality the added capacity is spread 
across all of the native drives in the environment enabled by the methods described in this 
invention. This method of capacity distribution is clearly not the only possible. There are 
other algorithms (e.g., a certain portion of the overall added capacity could be assigned to 
each native drive - not the entire amount) that could be used but they are immaterial to the 
nature of this invention.. 

The SAL processes (400a, 400b and 400c in Fig 3c) are creating these logical drives, or 
storage objects, but the actual usage of the External Storage Subsystem 16 will be managed 
by the SSMS processes 500. As part of the discovery and initial configuration process the 
SAL Administration process (440 in Fig 4) communicates with the SS Administration 
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process 530. Part of this communication is to negotiate for the initial storage partitioning. As 
illustrated in Fig 9 each attached, HSOA enabled client is allocated some initial space (e.g., 
double space of native drive) 

1. Drive element 103a (Chassis 100a C-Drive) is allocated 30 GBytes 910 

2. Drive element 104a (Chassis 100a D-Drive) is allocated 40 GBytes 920 

3. Drive element 103b (Chassis 100b C-Drive) is allocated 60 GBytes 930 

4. Drive element 103c (Hub 13 Native-Drive) is allocated 120 GBytes 940 
and some reserved space (typically, 50% of the allocated space) 

1 . Drive element 103a (Chassis 100a C-Drive) is reserved an additional 15 GBytes 
911 

2. Drive element 104a (Chassis 100a D-Drive) is reserved an additional 20 GBytes 
921 

3. Drive element 103b (Chassis 100b C-Drive) is reserved an additional 30 GBytes 
931 

4. Drive element 103c (Hub 13 Native-Drive) is reserved an additional 60 GBytes 
941 

by the SS Administration process 530. 

Again, this allocation is only an example. Many alternative allocations are possible and fully 
supported by this invention. 



Details of this allocation are, again, provided earlier in the OPERATION OF INVENTION - 
STORAGE EXPANSION AND BASIC SHARING section and in Table III (below). 







Table in 






Steering Table - 


Logical C-Drive 


Logical Address Range 
(word = 4 bytes) 


Drive 


Interface 


Actual/Physical 
Drive Address 


Notes/Actions 


1-3,750,000,000 


C 


DiskO 


1 - 

3,750,000,000 


Access Native Drive 


3,750,000,001 - 12,500,000,000 


Ext SS 


Diskl 


1 - 

7,500,000,000 


Access External Storage Subsystem 
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12,500,000,001 - 15,000,000,000 


Ext SS 


Diskl 


7,500,000,001 - 
11,250,000,000 


Using up the reserved area, have 
Administration process increase 
reserve space 


15,000,000,001 - max address 


NA 


NA 


ERROR 


Error, has to be handled as an out 
of bounds condition 



Once the basic tables are set up (e.g. Table III), HSOA enabled client operations proceed in a 
manner similar to that described previously. The SAL File System Interface process (420 in 
Fig 4) intercepts all storage element requests. These pass on to the SAL Virtual Volume 
Manager process (430 in Fig 4) that, through use if its logical volume tables, either responds 
to the request directly (a volume size query, for example) or passes the request on to the 
Access Director process (450 in Fig 4). Requests that pass on to the Access Director 450 
imply that the actual device is accessed (typically a read or a write). The Access Director 
450, through use of its steering tables (451 in Fig 4), dissects the logical volume request and 
determines which physical volume to address and what block address to utilize. 

In the case in hand (the environment illustrated in Fig 3c with the External Storage 
Subsystem 16, encompassing an additional 400 GBytes of storage capacity, configured as an 
extension to the internal disk drives 103a, 103b, 103c, and 104a, as outlined above), assume 
that the client represented by PC chassis 100a is accessing its logical C-drive at address 
6,000,000,000 (word address, with a word consisting of 4 bytes). In an actual environment 
addressing methodologies can vary, these addresses are simply used to convey the 
mechanisms and processes involved. The SAL Virtual Volume Manager process (430 in Fig 
4) determines that this is a read/write operation for its logical C-drive. This is passed along to 
the Access Director (450 in Fig 4). The Access Director 450 utilizes its steering table (451 in 
Fig 4, and Table III above) to determine how to handle the request. The logical disk address 
is used as an index entry into the table (e.g. using the Logical Address Range column in 
Table III). This will then indicate that the External Storage Subsystem 16 must be accessed, 
using the Disk Driver (370 in Fig 4) and Disk Interface 1 (372 in Fig 4). The table indicates 
the appropriate driver, if more than one exists, and the adjusted address. In this case a local 
address 6,000,000,000 maps to remote address of 2,250,000,000. Once this determination is 
made, the Access Director 450 passes the request to the appropriate connection process, in 
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this case the Disk Driver Connection process (470 in Fig 4). The connection process then 
appropriately packages, or encapsulates the request such that it passes to the correct standard 
Disk Driver (370 in Fig 4) that, in turn, accesses the device. In this case the device is an 
intelligent External Storage Subsystem 16 (Fig 3c) with processes and interfaces illustrated in 
Fig 5a. The HSOA enable client request is picked up by the External Storage Subsystem's 16 
Disk Interface 580 and Disk Driver 570. These are similar (if not identical) to those of a 
client system (reference numbers differ from the 370 and 371 sequence to differentiate from 
other Disk Driver and Interface in Fig 3). A Storage Subsystem (SS) Disk Driver Connection 
515 provides an interface between the standard Disk Driver 570 and a SS Storage Client 
Manager 520. The SS Disk Driver Connection process 515 is, in part, a mirror image of an 
enabled client's Disk Driver connection process (470 in Fig 4). It knows how to pull apart the 
transported packet to extract the storage request, as well as how to encapsulate responses, or 
requests, back to an enabled client. In this example the SS Disk Driver Connection 515 
extracts the read/write request to address 2,250,000,000 on the external storage portion of the 
logical volume. The SS Storage Client Manager 520 is cognizant of which enabled client 
machine is accessing the storage subsystem (and tags commands in such a way as to ensure 
correct response return. The SS Storage Client Manager 520 translates specific client 
requests into actions for a specific logical storage subsystem volume(s) and passes requests 
on to a SS Storage Volume Manager 540, or to a SS Administration 530. In this example, 
since the request is a simple read/write for a valid address, there are no triggers for any sort 
of expansion operation; the command passes along to the SS Volume Manager 540. The SS 
Volume Manager 540 may be a fairly standard volume manager process. It knows how to 
take the logical volume commands from the client SAL Virtual Volume Manager (430 in Fig 
4) and translate into appropriate commands for specific drive(s). The SS Volume Manager 
540 process handles any logical drive constructs (Mirrors, RAID, etc. . .) implemented within 
the External Storage Subsystem 16. The SS Volume Manager 540 then passes along the 
command to the SS Disk Driver Connection 560 that, in turn, passes the command to the 
Disk Driver 370 for issuance to the actual drive. A read command returns data from the drive 
(along with other appropriate responses) to the client, while a write command would send 
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data to the drive (again, ensuring appropriate response back to the initiating client). Ensuring 
that the request is sent back to the correct client is the responsibility of the SS Client 
Manager process 520. The SS Administration 530 handles any administrative requests for 
initialization and setup. 

An External Storage Subsystem 16 may be enabled with this entire SS process stack or an 
existing intelligent subsystem may only add the SS Disk Driver Connection 515, SS Client 
Manager 520 and SS Administration 530 processes in conjunction with a standard volume 
manager (et al). In this way the current invention can be used with an existing intelligent 
storage subsystem or one can be built with all of the processes outlined above. 

CONCLUSION, RAMIFICATIONS, AND SCOPE OF INVENTION 

Thus the reader will see that the Home Shared Object Architecture provides a highly 
effective and unique environment for: 

(1) Easily, and transparently expanding a clients native storage capacity 

(2) Allow for multiple clients or machines to utilize a single, common external storage 
element 

While the above description contains many specificities, these should not be construed as 
limitations on the scope of the invention, but rather as an exemplification of one preferred 
embodiment thereof. Many other variations are possible. For example: 

• Don't have to be Windows based PCs; can be MACs, Unix or Linux based 
servers. 

• Home network can be implemented in many ways; could be as simple as multiple 
USB links directly from "enabled client(s)" directly to the intelligent storage 
device. 

Accordingly, the scope of the invention should be determined not by the embodiments) 
illustrated, but by the appended claims and their legal equivalents. 
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